home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group96a.txt / 000155_icon-group-sender _Thu Jul 11 13:06:27 1996.msg < prev    next >
Internet Message Format  |  1996-09-05  |  1KB
  1. Date: Thu, 11 Jul 1996 13:06:27 MST
  2. From: icon-group-sender
  3. Message-Id: <199607112006.AA10303@cheltenham.cs.arizona.edu>
  4. Received: by cheltenham.cs.arizona.edu; Thu, 11 Jul 1996 13:06:27 MST
  5. Errors-To: icon-group-errors@cs.arizona.edu
  6. Apparently-To: icon-group-addresses
  7. Status: O
  8.  
  9. already) completely locks the color palette, so I can't build my image,
  10. unless I use the precise same palette.
  11.  
  12. The only `solution' I've found is to process the image for what it is: 
  13. a stream of numeric data, not to be loaded in memory as an image for any
  14. reason---ludicrous.
  15.  
  16. Unless I've missed something, I think that some better facility  for 
  17. handling color bitmaps would be needed.  I don't know, the ability to
  18. declare explicit color palettes, and some simple color-mapping algorithm
  19. for CopyArea between `incompatible' bitmaps would be nice.
  20.  
  21. I believe that most of the facility is already present---considering color 
  22. palettes---the ability to have user defined palettes would be crucial.
  23. -- 
  24. [nosave]<http://www.eleves.ens.fr:8080/home/espie/index.html>
  25. microsoft network is EXPLICITLY forbidden to redistribute this message.
  26. `Seiza no matataki kazoe, uranau koi no yuku e.'
  27.     Marc Espie (Marc.Espie@ens.fr)
  28.